\documentclass{report}
\usepackage[utf8]{inputenc}
\usepackage[francais]{babel}
\usepackage[T1]{fontenc}
\usepackage{lmodern}
\usepackage{ifpdf}
\usepackage{graphicx}
\usepackage{geometry}
\usepackage{color}
\usepackage{pdfpages}
\usepackage{slashbox}
\usepackage{chemist}

\definecolor{orange}{rgb}{0.8, 0.4, 0.1}
\definecolor{vert}{rgb}{0.27, 0.57, 0.13}
\definecolor{marron}{rgb}{0.6, 0.2, 0.13}
\renewcommand{\familydefault}{\sfdefault}

\geometry{hmargin=50pt, vmargin=50pt}

\title{Rapport de projet : Chemicall}
\author{Geoffrey Mélia  \and Kevin Bollini \and Nathalie Glad \and Ailin Moreno \and Thomas Hinsinger}
\date{\today}
\ifpdf
	\pdfinfo 
	{
		/Author (kbollini,nglad,thinsinger,gmelia,amoreno)
		/Title (Rapport de projet)
		/Subject (Tableau virtuel interactif)
		/Keywords ()
		/CreationDate (\today)
	}
\fi

\begin{document}
	% Page de titre
	%\maketitle
	\thispagestyle{empty}
\begin{picture}(40,40)
\put(50,-600){\rule{.2mm}{21cm}}
\put(-50,-70){\rule{20cm}{.2mm}}

\put(70,-50){\textsc{\Huge{Chemicall}}}
\put(360,-100){\textsc{\Large{Rapport de projet}}}
\put(350,-120){\textsc{\large{Serious Game}}}

\put(100,-220){\textsc{\large{Kevin Bollini, Nathalie Glad, Thomas Hinsinger}}}
\put(100,-240){\textsc{\large{Geoffrey Mélia, Ailin Moreno}}}

\put(120,-500){\includegraphics[scale=0.7]{../images/happy_HD.png}}
%\put(160,-455){\includegraphics[scale=0.4]{um2.jpg}}

\put(230,-530){\textsc{\large{Master informatique}}}
\put(205,-550){\textsc{\large{Année universitaire 2012/2013}}}
\end{picture}
	
	\thispagestyle{empty}
	\newpage
	
	% Sommaire
	\tableofcontents

	%Table des figures
	\listoffigures
	
	\newpage
	%TODO : grossir, centrer sur la page
	\section*{Remerciements}
	\addcontentsline{toc}{section}{Remerciements}
	\paragraph{}
\begin{itemize}
\item Damien Djaouti, pour ses conseils avisés en matière de Game Design.
\item Abdelkader Gouaich pour ses cours et pipeline de développement.
\item Nastassia Jacquet pour son aide précieuse en matière de sound design et de bruitage.
\item Frédéric Tari, pour avoir partagé ses connaissances et son affinité pour la musique.
\item Camille Seilles, pour ses réalisations graphiques de notre avatar oxygène sous ses différentes formes.
\end{itemize}
	\part{Rapport de projet}
	\newpage
	\chapter{Introduction}
		\section{Présentation du jeu}
	Dans le cadre du Master 2 informatique, nous avons été amenés à concevoir notre serious game et l'avons axé sur le thème de la chimie.\\
Notre projet est un jeu de plate-forme 2D à la manière d'un puzzle game, aux graphismes ludiques permettant d'aborder les notions élémentaires de chimie, comme les éléments de base ou l'existence de certaines interactions.\\
\\
	 Le joueur incarne un atome d'oxygène qui doit délivrer d'autres atomes, lui permettant par là même d'augmenter ses capacités grâce aux interactions chimiques qu'il pourra alors réaliser. Dans sa quête, il rencontrera des entités ayant un électron en moins ou en plus et qui lui feront perdre ou gagner des électrons : les ions. Il devra sortir du niveau en étant stable afin de gagner un nouvel atome.
Dès lors, le joueur apprendra à utiliser ce nouvel atome avec celui d'oxygène afin de créer une molécule ayant des propriétés particulières.
 Il pourra alors, appeler un de ces atomes gagnés, lors des prochains niveaux afin de modifier son état physique et franchir les obstacles.
		\paragraph{}

		\begin{figure}[!h]
			\centering
			\includegraphics[scale=0.3]{../images/ingame.png}\\
			\caption{Aperçu de l'application}
			\label{Aperçu de l'application}
		\end{figure}
	\newpage
		\section{Contexte}
Ce jeu a été pensé et conçu pour les enfants âgés de 10 à 14 ans dont la scolarité amène à apprendre les premières notions de chimie. Le choix de ces notions dans le contenu pédagogique de notre jeu a donc été réalisé en fonction des connaissances chimiques attendues d'un enfant de cet âge.\\
Nous avons dans un premier temps étudié les notions importantes à mettre en valeur dans notre jeu puis, dans un second temps, la manière dont ces notions pouvaient être intégrées au jeu afin de suivre une visée pédagogique.\\
		\subsubsection{Éléments de chimie}
L'atome est un élément essentiel de la chimie et en compose la base : nous avons choisi de l'utiliser comme l'élément central du jeu. Notre objectif étant de faire apprendre :
\begin{itemize}
\item les notions d'interactions entre atomes ainsi que l'état physique résultant.
\item Les relations entre électrons et atomes
\item Les différents états de l'atome en fonction de son nombre d'électrons.
\end{itemize}
~\\ Au vue des programmes scolaires de chimie, le premier élément complexe, ou molécule, appris est l'eau. Nous avons donc penser utiliser les atomes le composant : l'oxygène ou l'hydrogène. Étant donné que l'hydrogène n'a que deux électrons et que pour notre idée de jeu, ceci était trop faible, nous avons décidé de garder l'atome oxygène.\\
De plus, l'oxygène est un élément simple qui s'associe facilement avec d'autres atomes, ce qui était intéressant pour notre gameplay.
Nous pouvons facilement créer les molécules simples comme le dioxygène et l'eau.
		\subsubsection{Intégration}
Après avoir réfléchi aux éléments et aux notions de chimie que nous souhaitions intégrer, nous nous sommes intéressés à la manière la plus adéquate pour fondre dans le jeu ces différents éléments.\\
L'atome étant l'élément central du serious game, nous avons décidé de l'utiliser comme personnage principal. Afin de proposer un challenge au joueur, nous voulions intégrer des personnages ennemis ou alliés dans le jeu. Étant donné que nous souhaitions introduire la notion d'électrons, l'idée d'anion et de cations nous apparu rapidement comme la solution la plus adéquate.\\
Pour l'association avec d'autres atomes, nous avons pensé à plusieurs possibilités telles que les intégrer directement dans le niveau comme un pouvoir disponible par exemple. Mais ceci ne nous apportait pas de solutions permettant de proposer un challenge intéressant pour finir le niveau. Nous avons donc décidé de l'intégrer à la fin de la réussite d'un niveau et de pouvoir expliquer l'intérêt d'utiliser cet atome.

	\chapter{Analyse et conception}
		\section{Gestion du projet}
			Pour le développement de ce projet, nous avons décidé d'utiliser une méthode AGILE. Nous avons procédé par série de sprints, visant à développer des versions prototypes du jeu puis  à les enrichir par itérations successives.\\ \\
		\begin{tabular}{| l | c || r ||}
			 \hline                 
				Version du Prototype & Contenu et Ajouts majeurs & Durée (Jours)\\
			\hline
				1 & Atome évoluant en 2D sans gravité ni collisions  & 3 \\
        					&  Création du projet et du dépôt & \\
			\hline
				2 & Atome soumis à une gravité  & 2 \\
					& Ajout du moteur Physique & \\
			\hline
				3 & Atome évoluant sur des plateformes physiques, pouvant effectuer des sauts & 3 \\
					&  Ajout des collisions entre entités & \\
			\hline
				4 & Entités du jeu animés & 2 \\
					& Modification de la classe gérant les sprites pour les animer & \\
			\hline
				5 & Ajout des entités Anion Et Cation & 2 \\ 
					&  Restructuration des classes du projet & \\
			\hline
				6 & Atome pouvant échanger des électrons avec les autres Atomes & 2 \\
					& Modification complète des collisions & \\
			\hline
				7 & Sonorisation du prototype & 2 \\
					& Ajout librairie FMOD & \\
			\hline
				8 & Niveau pouvant être parcouru via scrolling & 3 \\
					&  Ajout d'une caméra et d 'une interface utilisateur & \\
			\hline
				9 & Ajout d'un menu de jeu & 2 \\
					&  Création d'un Game Manager & \\
			\hline 
				10 & Premier prototype avec graphisme définitifs & 5 \\
					&  Création des assets finaux et d'un Level Manager & \\
			\hline 
				11 & Prototype avec niveaux pouvant être terminés & 4 \\
					& Ajout d'éléments graphiques à l'interface et création de la sortie de niveau & \\
			\hline  
 \end{tabular}
\newpage
		\section{Outils utilisés}
			\subsubsection{Outils techniques}
				\begin{itemize}
					\item Integrated Development Environment : Visual C\# 2010
					\item Gestionnaire de version : Subversion
					\item Communication : Mails, outils de vidéoconférence,  éditeur de documents collaboratif
				\end{itemize}
			\subsubsection{Langages :}
				\paragraph{} Pour le développement  du projet nous avons décidé d'utiliser le langage de programmation C\#, après  une étude préalable.
En effet ce choix n'est pas du au hasard. La principale raison de celui-ci est l'opportunité de découvrir une technologie non traitée au cours de notre formation, dans le cadre d'un projet conséquent.
D'autre part, ce langage semblait le plus approprié au projet car permettant un développement assez rapide de jeu grâce au Framework XNA.
			\subsubsection{Frameworks :}
				Le jeu utilise trois Frameworks, chacun influant sur un des moteurs du jeu. le choix de l'utilisation de ces composants s'est fait pour permettre l'accélération et la qualité du développement.
	\paragraph{XNA} est un ensemble d'outils facilitant le développement de jeu sur les terminaux Microsoft. (Xbox360, Windows Phone, Windows)\\
Notre choix d'utiliser cette technologie fait suite à notre envie d'utilisation d'outils qui ne nous sont pas connus. D'autre part, XNA est très bien documenté et complètement orienté sur le développement de jeux vidéos grands public.
	\paragraph{Farseer Physics} est un moteur physique libre basé sur le réputé moteur BOX2D. Ce moteur est spécialement conçu pour être utilisé avec XNA, et permet l'implémentation d'interactions physiques réaliste dans le jeu. Ce moteur permet en outre une gestion complète des collisions entre les entités.\\
Notre choix s'est porté sur ce moteur pour diverses raisons. Tout d'abord, il spécialement conçu pour fonctionner avec XNA. De plus il possède une documentation complète et une communauté active et est le seul portage C\# de BOX2D à être constamment maintenu.
	\paragraph{FMOD} est un moteur sonore permettant  une gestion complète de la sonorisation d'un jeu. Initialement conçu pour le langage C, celui-ci possède un binding officiel pour le C\#, permettant l'utilisation de la librairie C.\\
Notre choix s'est porté sur cette technologie car c'est le framework qui nous a été enseigné dans l'UE "Sons et Musique",  UE pour lequel une partie de notre groupe réalise la sonorisation du jeu.
			
		
		\newpage
		\section{Analyse}		
			\subsection{Diagramme de classes}
				
				%TODO présentation structure \\
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.45]{../images/diagrammeClasseChemicall_lite.png}\\
						\caption{Pseudo-Diagramme de classe}
						\label{Pseudo-Diagramme de classe}
				\end{figure}						
	
	\chapter{Réalisation}
		Dans ce chapitre nous détaillerons les points essentiels de notre réalisation en illustrant une partie des composantes développées pour le jeu.
		\section{Game Engine}
			La première chose que nous avons réalisé est le moteur du jeu, celui-ci utilise le framework XNA pour les logiques de base (Boucle principale. dessin de la scène etc.) et le moteur physique Farseer.
			Ainsi, nous avons donc développé des "briques" de bases, utilisant ou non le moteur physique, permettant la construction des niveaux : nous appellerons ces briques les "Entités";
			\subsection{Entités}
				On peut distinguer deux types d'entités, les Sprites et les entités physiques. La différence entre ces deux composants est triviale, l'une n'est pas soumise au contrainte du monde physique auquel il appartiens, à contrario de l'autre. 
				\subsubsection{Sprite}
					Cette entité est à la base de tout le système, elle permet l'affichage à l'écran à une position donnée d'un élément graphique. Cet élément peut être animé, de la taille de son asset graphique ou non (permettant la création de texture). Cette classe d'entité est mère de toute entité ayant une texture à afficher, que ce soit un élément d'interface, un acteur physique ou simplement un arrière-plan.
				\subsubsection{Physique}
					A la différence d'une simple sprite, une entité physique possède un corps tangible, de forme ronde ou polygonale, soumis aux interactions du monde. Cette classe d'entité est donc la base de tout élément interactif du jeu, de la plateforme à l'agent en passant par les éventuels interrupteurs et autres portes. On distingue tout de même deux types d'entités physiques, les entités statiques et celles dynamiques. Il faut noter qu'une entité physique est aussi une sprite, son corps étant dans la majorité des cas un rectangle de la taille de son asset graphique.
					\paragraph{Entités Statiques :} Elles permettent la création de toutes les entités qui ne bougeront pas dans le jeu (plateformes, portes etc.) L'intérêt de ces entités est qu'elles ne sont soumises à aucune force extérieure ( gravité, frottements, etc).
					\paragraph{Entités Dynamiques :} Elles permettent la création de tout ce qui va être soumis à l'environnement du jeu, les acteurs par exemple. C'est cette différence qui permet d'obtenir une gravité et des mouvements réalistes des entités du jeu. Ces entités peuvent être par exemple des blocs que l'on peut pousser ou un mur que l'on peut briser.
					\paragraph{Agents :} ils sont une sous classe des entités dynamiques, ils se différencient des entités dynamiques par le fait qu'ils peuvent être animés par un comportement ou un mouvement sur un parcours par exemple.
					\paragraph{Character :} Il permet le contrôle d'un personnage, il se différencie des agents par le fait que son comportement est dicté par le joueur.
			\subsection{Feedback}
				\paragraph{} Les éléments du feedback donnent au joueur un élément d'immersion dans le jeu. Cette importante constatation nous à amener au développement de quelques éléments de retour comme le menu, les infobulles, la modification dynamique d'assets graphiques ou du son. 
				\paragraph{Menu :} Les menus sont une guide au joueur pour initialiser le jeu, sauvegarder une partie, éliminer une partie, faire une sélection de niveaux, etc. Nous avons dans un premier temps rassemblé les éléments communs à tous les menus dans une classe parente pour ensuite faire chaque menu avec ses options. Nous comptons avec plus de 10 écrans de menu (écran de pause et menu de réglages inclus) pour garantir au joueur une navigation et une utilisation intuitives. 
				\paragraph{Infobulles :} Les infobulles sont des éléments « ingame » que permettent un retour pédagogique au fur et à mesure du déroulement du jeu. Ces éléments donnent des informations au joueur sur, par exemple, les conséquences de toucher un anion/cation. L'idée est de notamment donner au joueur des explications qui peuvent être testées lors du jeu et ainsi doter ce dernier des principes sérieux.
				\paragraph{Son :} Nous nous sommes également occupés d'inclure dans notre projet des fichiers de son pour la sélection des options de menu, saut et collision des personnages. Ceci permet une immersion tout en contribuant à garantir que le joueur ne s'ennuie pas.

		\section{Game Manager}
			\subsection{Utilité}
				Lors de la conception de notre Serious Game, nous avions trouvé une fonctionnalité intéressante à développer : la sauvegarde et le chargement d'une partie lors de l'exécution de notre jeu. En effet, il est assez déroutant de jouer à une partie et de quitter celle-ci puis, lors du relancement du jeu, de ne plus pouvoir reprendre la partie là où elle en était.
				
				Il était donc important pour nous que cette fonctionnalité soit présente dans notre Serious Game.
			\subsection{Conception}
				\subsubsection{Game Manager}
					Voici comment se présente ce Game Manager : 
					\begin{figure}[!h]
							\centering
							\includegraphics[scale=0.8]{../images/gameManager.png}\\
							\caption{Game Manager}
							\label{Game Manager}
					\end{figure}
					\newpage
					\paragraph{Paramètres :}
					\begin{itemize}
						\item GameManager instance : l'instance unique du GameManager s'utilisant dans notre Serious Game
						\item String fichier : l'adresse de notre fichier de sauvegarde
						\item string nameUser : le pseudo du joueur
						\item bool[] tNiveau : un tableau de boolean où sont stockés tous les niveaux réussis au moins une fois par le joueur
						\item int[] tScore : un tableau d'entiers où sont stockés les scores de chaque niveaux réussis par le joueur
						\item bool[] tAtome : un tableau de boolean où sont stockés les atomes gagnés par le joueur lorsqu'il termine un niveau en étant stable
					\end{itemize}
					\paragraph{public static GameManager getInstance() :}fonction permettant de récupérer l'instance unique de GameManager en utilisant le pattern Singleton. Cela nous permet d'être certain qu'au cours de l'exécution de notre Serious Game une seule instance de GameManager est modifiée.
					\paragraph{private GameManager() :} constructeur d'un GameManager
					\paragraph{public void LoadGameManager(string fichier)  }fonction permettant de charger un GameManager à partir d'un fichier de sauvegarde et donc de charger la sauvegarde du joueur.
					\paragraph{public void SaveGameManager(string fichier, string name) :}fonction permettant de sauvegarder un GameManager. Cette fonction est appelée à chaque fois que le joueur termine un niveau, et elle se fait donc automatiquement sans que le joueur ait besoin de sauvegarder lui même sa partie.
					\paragraph{public void EraseGameManager(string fichier) :}fonction permettant de supprimer un GameManager. Cette fonction est utile lorsque le joueur veut créer une partie et que le nombre maximal de sauvegardes est atteint (comme dans Pokemon). Il doit donc supprimer une partie enregistrée pour pouvoir créer sa partie.
					\paragraph{public void SaveLevel(int numeroNiveau, bool niveau, int score, bool atome) :\label{savelevel}}cette fonction sauvegarde un niveau dans le GameManager. Elle prend le soin de vérifier si le joueur a déjà réussi à finir ce niveau et si oui ne met à jour le score que si celui-ci est meilleur.
					\paragraph{public string LoadNameSave(string fichier) :}fonction permettant de trouver le pseudo du joueur à partir du fichier de sauvegarde.
							
				\subsubsection{Fichier de sauvegarde}
					Le fichier de sauvegarde est un fichier texte. Pour que cela soit possible il faut que le fichier soit de cette forme là uniquement : 
					\begin{figure}[!h]
						\centering
						\includegraphics[scale=1]{../images/sauvegarde.png}\\
						\caption{Fichier de sauvegarde}
						\label{Fichier de sauvegarde}
					\end{figure}	
					\begin{itemize}
						\item \textbf{Thomas : } le pseudo du joueur
						\item \textbf{2 : } le nombre de niveau disponible dans le Serious Game
						\item \textbf{True\\
						False : } les niveaux terminés par le joueur
						\item \textbf{2\\
						0 : } les scores obtenus pour chaque niveau du joueur
						\item \textbf{True\\
						False :} les atomes obtenus par le joueur 
					\end{itemize}
		\section{Level Manager}
			\subsection{Utilité}
Une autre 'brique' importante dans le moteur de notre Serious Game est le LevelManager. Chemicall est en effet en jeu divisé en plusieurs niveaux comme cela se fait couramment dans le monde du jeu vidéo. Cette décomposition permet de proposer facilement un gameplay évolutif, tant du point du vue du contenu que de celui de la difficulté. Le LevelManager va donc permettre de gérer les différents niveaux du jeu au sein du programme. Il est intimement lié au GameManager puisque chaque joueur, en fonction de son avancement dans le jeu, n'aura par exemple pas accès aux même niveaux ni aux même pouvoirs. C'est aussi lui qui gère les éléments propres à un niveau, leur mise-à-jour ainsi que leur éventuel affichage dans l'interface graphique ou leur transmission au GameManager (sauvegarde des scores, niveaux débloqués, etc).

			\subsection{Fonctionnement et Conception}
				\subsubsection{Description d'un Level \label{leveldescription}}
Le LevelManager, comme son nom l'indique, gère les différents niveaux de jeu. Voyons donc dans un premier temps la manière dont sont construits ces Levels. \\
Nous souhaitions pouvoir créer et utiliser nos niveaux de manière indépendante. Nous avons ainsi décidé d'utiliser un système bien adapté aux stockage de données et à leur manipulation par différents systèmes : le XML. Cela nous permet de bien différencier la description d'un Level de son utilisation dans le jeu, ainsi que de facilement étendre la définition ou le contenu d'un Level.
Il a tout d'abord fallu identifier les éléments propres à un Level afin d'en définir la structure. Il est apparu qu'en plus du numéro et du nom du niveau, une simple liste des entités présentes dans le niveau suffisait à décrire ce dernier.
 				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.98]{../images/LevelDescription.png}\\
						\caption{Description d'un niveau}
						\label{Description d'un niveau}
				\end{figure}
 \\Une entité étant elle caractérisée par son type, sa position initiale et sa dimension :
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=1]{../images/EntityDescription.png}\\
						\caption{Description d'une entité}
						\label{Description d'une entité}
				\end{figure}
\\ Ces descriptions, bien que très simplistes, suffisent à définir l'intégralité du contenu d'un niveau. Cette approche permet par ailleurs d'enrichir aisément le contenu d'un niveau : \\
\begin{itemize}
	\item {en quantité : } en remplissant simplement la liste des entités
	\item {en variabilité : } en utilisant un nouveau type d'entité
\end{itemize}
Cette définition semble donc robuste aux changements, comme nous avons d'ailleurs pu le constater tout au long du projet.
	\subsubsection{Fichiers XML}
A partir de ces définitions, il est alors simple de créer autant de niveaux que nous le souhaitons en créant des fichiers XML respectant cette syntaxe. En voici un exemple volontairement épuré.
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=1]{../images/LevelXML.png}\\
						\caption{Définition d'un niveau en XML}
						\label{Définition d'un niveau en XML}
				\end{figure}
\subsubsection{Chargement et exploitation des données}
Une fois notre banque de niveaux créée, il faut alors pouvoir charger les données des fichiers XML afin de les exploiter dans l'application. C'est là un des rôles principaux de notre LevelManager. Il est temps de regarder d'un plus près son fonctionnement (Figure \ref{Level Manager})
\newpage
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.9]{../images/LevelManager.png}\\
						\caption{Level Manager}
						\label{Level Manager}
				\end{figure}
\paragraph{}Notons tout d'abord qu'il ne peut y avoir qu'une instance unique du LevelManager. Il ne serait pas utile d'en avoir plus et cela risquerait de créer des conflits.
\paragraph{Méthodes importantes : }
\begin{itemize}
\item \textbf{LoadLevel(int numLevel) : }Appelée lorsque l'on souhaite charger (ou recharger) un niveau. Elle se charge d'appeler la méthode resetLevelManager() pour réinitialiser les données puis charge les informations spécifiques au niveau souhaité grâce à la seconde méthode LoadXMLLevelDescription. \\
\item \textbf{LoadXMLLevelDescription(String XMLLevelFile) : }Permet de de lire le fichier XML de définition du niveau, et convertit les données lues en données utilisables par l'application en suivant les descriptions LevelDescription et EntityDescription détaillées en \ref{leveldescription}.\\
\item \textbf{EndLevel() : }Se charge d'envoyer l'état des informations importantes à la sauvegarde de données au GameManager, en utilisant notamment sa fonction SaveLevel (cf \ref{savelevel}).\\
\end{itemize}
\newpage
	\chapter{Résultats}
		\section{Assets Graphiques}
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.6]{../../chemicall/chemicallContent/oxygen.png}\\
						\caption{SpriteSheet de l'oxygen}
						\label{SpriteSheet de l'oxygen}
				\end{figure}
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.6]{../../chemicall/chemicallContent/spriteSheetBarInterface.png}\\
						\caption{Interface de décompte des électrons}
						\label{Interface de décompte des électrons}
				\end{figure}	
\newpage
		\section{Prototype}
			\subsection{Menus}
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.6]{../images/menu.png}\\
						\caption{Menu du jeu}
						\label{Menu du jeu}
				\end{figure}

				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.6]{../images/menuNiveau.png}\\
						\caption{Sélecteur de niveaux}
						\label{Sélecteur de niveaux}
				\end{figure}	
\newpage
			\subsection{Ingame}
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.6]{../images/ingame2.png}\\
						\caption{Capture ingame du jeu}
						\label{Capture ingame du jeu}
				\end{figure}
				\begin{figure}[!h]
						\centering
						\includegraphics[scale=0.6]{../images/ingame3.png}\\
						\caption{Capture ingame du jeu avec feedback}
						\label{Capture ingame du jeu avec feedback}
				\end{figure}	

	\chapter{Discussion}
		\section{Difficultés rencontrées}
		
		Le projet étant un serious game basé sur les propriétés fondamentales de la physique et de la chimie, la première difficulté a été d'imaginer un gameplay autour de ces propriétés,en conciliant plaisir de jeu et respect des lois physico-chimiques.
		
		\subsection{Synchronisation}
Pour un projet d'une ampleur comme celle de Chemicall, un groupe de travail de cinq personnes travaillant toutes à distance impose nécessairement des exigences fortes quant à la synchronisation et aux méthodes de travail. La méthode AGILE utilisée a pour concept la répartition du travail par affectation de tâches. Or toutes les tâches ne peuvent pas être indépendantes et il arrivait donc fréquemment qu'il faille attendre qu'une tâche affectée à une autre personne soit terminée pour que la notre puisse fonctionner. Nous avons bien sur réparti les tâches de manière à ce que cette situation soit la moins fréquente possible tout en tentant de répartir le travail de manière équilibré et en fonction des capacités et souhaits de chacun.\\
C'est donc un gros travail d'équipe qu'il fallut faire, et la communication au sein du groupe a été très importante pour garantir un avancement constant du travail sans tâche bloquante retardée.

		\subsection{Technique} 
			Une des difficultés majeures du projet fût de réussir à importer toutes les librairies externes et faire les fonctionner correctement entre elles. La librairie sonore Fmod notamment n'est pas destinée pour le C\# et a demandé plus de temps et de recherche avant de fonctionner.
D'autre part, étant tous des programmeur et en aucun cas des graphistes, la création des assets graphiques à été assez chrono-phage et très laborieuse.
Enfin, toute les technologies utilisées étant nouvelles pour nous, une des grandes difficulté à été le temps de formation de chacun pour réussir à correctement tout manipuler.		

	          		\section{Impact Sérieux}			
		\subsection{Elements graphiques}
Nous allons détaillé la manière dont les éléments ont été pensé afin de réaliser une visée pédagogique.\\
Les éléments graphiques ont une place importante dans la compréhension du jeu. Comme détaillé auparavant, les différents éléments graphiques choisis permettent d'intégrer des éléments de feedback à une dimension "sérieuse".\\
\\
Concernant l'affichage du joueur, celui-ci commence stable donc nous avons choisi une image représentant le bien-être avec un sourire. Dès lors que le joueur n'est plus stable ,plusieurs éléments graphiques lui permettent de comprendre l'état du jeu: 
\begin{itemize}
\item Un affichage texte  s'affiche, permettant d'informer le joueur. Le mot "exces" ou " default" s'affiche si le joueur a reçu ou perdu , respectivement, un électron.\\ 
L'affichage de texte permet de faire comprendre rapidement au joueur, dans quelle situation il se trouve et si il est en excès ou en manque d'un électron.

\item La barre du nombre d'électrons se modifie. Si ce dernier lui en manque ou en possède trop, il passera alors dans le rouge permettant d'indiquer au joueur que cette situation n'est pas la bonne. En effet, plusieurs recherches ont montrés que le rouge était associé au mal ou à l'erreur et à l'inverse, le vert comme étant juste ou correcteur, c'est pourquoi nous avons choisi trois couleurs : le rouge, le vert et le jaune. Le jaune étant uniquement la transition entre le vert et le rouge. Ceci est uniquement psychologique. Il permet au joueur d'avoir un feedback rapide sur sa situation.

\item L'affichage de l'atome du joueur change. Il possède alors le même affichage qu'un atome trop/peu chargé comme les éléments du jeu qu'il peut rencontrer. Afin de modéliser visuellement, cette échange d'électrons, l'anion/cation touché devient stable et prends donc l'affichage adéquat et le joueur se retrouve alors dans un état d'excès ou de manque et cela se visualise par l'affichage de l'agent touché.
\end{itemize}

	 \subsection{Visée pédagogique}
Nous allons nous intéresser à ce que le joueur apprend au cours du jeu.
\\
		\subsubsection{Anion / Cation}
A la suite de l'apprentissage des règles du jeu, le joueur comprend qu'il peut gagner ou perdre un électron comme dans la chimie réelle. Pour cela, il doit rencontrer des autres atomes, ayant un électron en plus ou moins, s'appelant respectivement anion et cation.
Il s'agit d'une information implicite, le joueur ne se souviendra peut-être pas du nom mais de l'existence de ces deux états de l'atome possible.
		\subsubsection{Electrons}
Grâce à la barre d'électron situé en haut à droite, le joueur apprend qu'un atome possède des électrons. Le nombre a été fixé à six, représentant les six électrons de la seconde couche de l'atome. Cependant, le but pédagogique visé est de faire comprendre au joueur les interactions possibles entres les atomes en échangeant des électrons. Ainsi, le joueur peut comprendre l'influence d'un élément sur son personnage et de comprendre que le personnage principal, représenté ici, ne doit pas être autre que stable.

                     \subsubsection{Associations d'atomes et leurs états physiques}
A la suite d'un niveau réussi, le joueur découvre un nouvel atome qui peut être associé à celui de son joueur afin de réaliser une molécule ayant une nouvelle propriété physique. Le joueur apprend différentes informations:
\begin{itemize}
\item Le nom d'un nouvel atome.
\item L'association possible avec son atome ainsi que la formule chimique.
\item La propriété physique associé à cette association.
\end{itemize}
~\\
Afin d'illustrer nos propos, en voici un exemple:\\
A la suite du premier niveau, nous gagnons l'atome hydrogène. Une fenêtre s'affiche et nous explique alors que l'hydrogène possède deux électrons et qu'il peut en partager un avec nous. Étant donné qu'il nous reste la possibilité de prendre encore deux électrons, on peut alors associer deux hydrogène avec l'atome oxygène afin de créer une molécule : l'eau.\\
On nous indique la formule chimique de cette molécule : \chemform{H_2O}\\
De plus, on apprend alors l'état physique de l'eau : liquide. On pourra alors passer à travers une grille.\\
A travers cet exemple, on retrouve les différents éléments cités dans la section auparavant. 

\paragraph{}
Afin de faciliter la compréhension pour l'utilisateur, nous avons décidé de réaliser des assets graphiques.\\
Nous avons réalisé les spriteSheet (Figure \ref{SpriteSheet de l'oxygen}) de l'atome d'oxygène mais également ceux des anions et cations permettant d'avoir des animations. La première ligne représente l'animation stable, son expression renvoit à une certaine joie. La seconde ligne represente l'animation dès lors qu'il possèdera un ou des électrons en plus,il semble fatigué. La dernière ligne représente l'animation dès lors qu'il lui manque un ou plusieurs éléctrons. Son visage est fermé, il est excité.\\
Il était important que la représentation de ces animations soit compréhensible par tous, c'est pourquoi, nous avons utilisé des expressions très différentes et significatives.\\
\begin{figure}[!h]
\centering
\includegraphics[scale=0.5]{../../chemicall/chemicallContent/oxygen.png}\\
\caption{SpriteSheet de l'oxygène}
\label{SpriteSheet de l'oxygen}
\end{figure}
\\
Concernant l'interface, nous avons réalisé un spriteSheet (Figure \ref{Interface de décompte des électrons}) modélisant le nombre d'électrons que possède le joueur. Comme nous l'expliquerons plus tard, la connotation du rouge et du vert n'est pas anodine. Les dessins ronds rappellent la forme d'un électron.		
				
	\chapter{Conclusion}
		
		\section{Conclusion}
		
		Nous sommes assez fier quand au résultat de notre prototype. Nous avons réussit à faire pratiquement tout ce que nous voulions faire. Notre avons ensemble longuement réfléchit à la conception de se prototype dans l'objectif non pas de rendre seulement un prototype mais un Serious Game complet et "commercialisable". 
		
		En effet, tout à été construit dans cette objectif là. Nous avons créer l'ensemble des entités que nous souhaitions mettre en place dans notre Serious Game. Nous avons qu'un prototype à ce jour, mais le LevelManager nous permet aisément de créer un niveau complet et bien construit. Il est donc facile par la suite de créer tous les niveaux nécessaire pour avoir un Serious Game complet et plaisant à jouer. 
		
		Tout à été pensé pour faciliter la création par la suite de notre Serious Game, le LevelManager pour la création de niveaux, le GameManager pour la sauvegarde et chargement de parties, SoundManager pour la créations des différents sons, ScreenManager pour la création des fenêtres de notre jeu, etc...
		
		Nous avons préférés construire quelque chose de bien fait, bien réfléchit que beaucoup de chose faite n'importe comment.

		\section{Perspectives}
		
		\paragraph{Transformations : } Il manque à ce jour certaine choses que nous aimerions faire par la suite. Comme par exemple l'association de notre personnage principal (l'Oxygène) avec un atome gagné. En effet, si le jouer termine un niveau et gagne l'atome d'Hydrogène, il doit pouvoir s'associer avec celui-ci pour se transformer en molécule H2O, l'eau. Et donc passer au travers de certaines zones du niveau, comme par exemple une grille. Évidemment, tout est en place pour pouvoir créer ces choses. 
		\paragraph{Le menu : } Nous avons un menu correct qui nous convient plus l'instant, mais il pourrait être amélioré et optimisé. En effet nous ne sommes pas des graphistes, nous ne sommes pas très doué dans ce domaine là. Ainsi notre background est très simple. De plus il manque quelques points à rajouté dans le menu (comme par exemple, la description détaillé des molécules H2O, CO2, etc... pour augmenter le côté sérieux de notre application), ou encore la possibilité de changer les raccourcis par défaut de notre application des les options, et d'autres choses encore.
		\paragraph{Les funnyfacts : } Nous avons mis en place la création d'infobulles permettant au joueur de comprendre ce qu'il se passe autour de lui. Nous avions dans l'idée de rajouter des funnyfacts lors d'un chargement d'un niveau pour apprendre des choses amusants sur la chimie au joueur. Cela augmenterait encore plus le côté sérieux de notre application.
		\paragraph{Les récompenses : } Nous voulions aussi mettre en place un système de badges pour différencier les joueurs. En effet en plus d'avoir un score par niveau, il aurait la possibilité de gagner des badges. Par exemple, si le joueur arrive à stabiliser tous les anions et cations du niveau en plus de rester stable, il gagnerait le badge Chimiste accompli. Cela rajoute un sentiment de satisfaction au joueur qui est intéressant à mettre en place.

	
	\chapter{Références}
	Sources web
	\begin{itemize}
		\item https://fr.wikibooks.org
		\item http://www.demonixis.net
		\item http://fr.wikipedia.org
	\end{itemize}

	
	\part{Annexes}
	\appendix
		\chapter {Diagrame de Classes}
		\begin{figure}[!h]
			\includegraphics[scale=0.18]{../images/diagrammeClasseChemicall.png}\\
			\caption{Aperçu de l'application}
			\label{Aperçu de l'application}
		\end{figure}
		\chapter{Game Design Document}
		\includepdf[pages = {1-6}]{GDD.pdf}
		\chapter{Etude Comparative}
		\includepdf[pages = {1-8}]{EtudeComparative.pdf}
\end{document}